Plan 9, A Distributed System 


Dave Presotto 
Rob Pike 
Ken Thompson 
Howard Trickey 

AT&T Bell Laboratories 
Murray Hill, New Jersey 07974 


ABSTRACT 

Plan 9 is a computing environment physically distributed across many machines. 
The distribution itself is transparent to most programs giving both users and administra- 
tors wide latitude in configuring the topology of the environment. Two properties make 
this possible: a per process group name space and uniform access to all resources by rep- 
resenting them as files. 


1. Introduction 

Plan 9 is a general-purpose, multi-user, portable distributed system implemented on a variety of com- 
puters and networks. Because commands, libraries, and system calls are similar to those of the Unix oper- 
ating system, it is possible to port many Unix programs to Plan 9 with little or no changes. A casual user 
would find little difference between the two systems. 

What distinguishes Plan 9 is its organization. The goals of this organization were to reduce adminis- 
tration and to promote resource sharing. Our programming style was minimalism. We believe that a small 
number of well-chosen abstractions can, with much less code, provide most of the function of a larger sys- 
tem. This is the approach that made the Unix operating system so much smaller than its contemporaries 
such as Multics. In building Plan 9, we generalized proven ideas from the Unix operating system rather 
than add new untried concepts. 

Plan 9 is divided along lines of service function. Diskless CPU servers concentrate computing power 
into large multiprocessors; file servers provide repositories for storage; and terminals give each user of the 
system a dedicated computer with bitmap screen and mouse on which to run a window system. The sharing 
of computing and file storage services provides a sense of community for a group of programmers, amor- 
tizes costs, and centralizes and hence simplifies management and administration. 

Since both CPU servers and terminals use the same kernel, users may choose whether to run pro- 
grams locally on their terminals or remotely on CPU servers. Plan 9 provides this flexibility without con- 
straining the choice. Therefore, both users and administrators can configure their environment to be as dis- 
tributed or centralized as they wish. At work, users tend to use their terminals more like workstations run- 
ning all interactive programs locally and reserving the CPU servers for data or compute intensive jobs such 
as compiling and computing chess end games. At home, connected via a dedicated 9600 baud line to work, 
users choose what they run locally and remotely to reduce communication cost. Some applications, such as 
the editor [Pik87], are split into multiple programs to make this choice even more flexible. 

Figure 1 in any Plan 9 paper shows how we have configured our environment. Multiprocessor CPU 
and file servers are clustered in a few computer rooms and connected via 7 megabyte/sec point-to-point 
links [Pre88]. This permits the CPU servers to be used as high performance compute engines without 
becoming starved for data. Terminals are connected to the servers via lower speed, lower cost distribution 
networks such as the 10 megabit Ethernet [Met80] and 2 megabit Incon [Kal, Res]. By emphasizing the 
shared service clusters we can quickly and cheaply incorporate new technologies as they arise. At the same 
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time, users wishing more autonomy can incorporate as much computing power as they wish in their own 
offices without losing the advantage of transparently sharing other resources. 



Figure 1 - Plan 9 Topology 

The rest of this paper describes the features of Plan 9 that make possible such a flexible topology. 
For more information on hardware and use of the system, see our previous paper [Pik90] . For details of 
the file server, see [Qui] . 

2. Minimalism 

All resources that a process can access, aside from program memory, reside in one name space and 
are accessed uniformly. Simply stated, all resources are implemented to look like file systems and, hence- 
forth, we shall call them file systems. A file system is a strict tree with no links. File systems can be the 
traditional type representing persistent storage on a disk as implemented by the shared file servers. They 
can also represent physical devices such as terminals or complex abstractions such as processes. The file 
systems can be implemented by kernel resident drivers, by user level processes, or by remote servers. 

A file system representing a physical device normally contains one or two files. For example, an 
RS232 line is represented as a directory containing a data and a ct 1 file. The data file is the stream of 
bytes transmitted/received on the line. The ctl file is a control channel used to change device parameters 
such as baud rate.f 

Some file systems represent software concepts. Environment variables (as in Unix) are implemented 
as files in a kernel resident file system. Even processes themselves are represented as directories with sepa- 
rate files representing different aspects of the process such as memory, text file, and control. Many things 
that require a system call in other operating systems are represented by I/O operations on files in Plan 9; 


t We neither need nor have an ioctl system call. 












- 3 - 


reading the id of a process, the user id associated with a process, the time, etc. 

A kernel data structure, called a channel , is used as a pointer to a file. A user level file descriptor is 
just a handle for a kernel channel. All I/O system calls eventually translate into nine primitive operations 
on channels. They are: 

attach- point a channel to the root of a file system. The file system is told which user is attaching. 

clone - make a copy of a channel. The new channel points to the same file as the old one. 

walk - do a one level directory lookup on the channel and point it to the new file (or directory). 

stat - get the attributes of the file pointed to. 

wstat - change the attributes of the file pointed to. 

open - check permissions prior to I/O on the channel. 

read - read from the opened file. 

write - write to the opened file. 

close - close the opened file. 

Each kernel resident file system is implemented by a device driver containing a procedure for each 
primitive operation. The device drivers are accessed indirectly via a kernel array, devtab, which con- 
tains 9 pointers per driver, one to each primitive procedure. Each channel contains an offset into dev tab 
indicating the driver to be used in accessing the file it points to. 

Accessing file systems not resident in the kernel is via a special device driver, the mount driver. All 
channels pointing to this driver contain a pointer to a communication channel. The mount driver turns 
operations on such channels into request messages written to the communication channel. The mount 
driver is written as a multiplexor allowing multiple outstanding messages. Because the messages on the 
communication channel are transmitted using read ' s and write's, any type of channel can be used: a 
pipe to a process, a network connection, even an RS232 line. The mount system call, described below, is 
used to create a new mount device channel and supply a communication channel for it. 

All Plan 9 components are connected using this file system protocol. The code used to encapsulate 
the primitives into request and reply messages is 580 lines long. The mount driver is 899 lines long. Com- 
pared to the equivalent NFS code implementing vnodes and XDR this is tiny. 

Of the 18000 lines of code that make up Plan 9, about 5000 lines perform memory management, pro- 
cess management, hardware interface, and system calls. The rest are for the 17 different file systems imple- 
menting devices, networks, process control, etc. Since most of the file systems are completely self con- 
tained, the complexity of the kernel code is even lower than its 18000 lines would imply. A working, albeit 
not very useful, kernel can be configured containing only the file systems implementing pipes, a local root, 
and a console. This totals 5899 lines of commented C code (counted using wc * . [ch] ). As a compari- 
son, Mach’s micro-kernel without device drivers has 25530 lines of C code (calculated, we’re told, by 
counting semi-colons). By the same metric our minimal kernel is only 4622 lines long, less than 1/5 the 
size. In fact, our kernel with every file system included is still less than half the size of their micro-kernel. 

One might note the similarities between devtab and parts of the Unix operating system; the block 
device switch, character device switch, file system switch and vnodes. One advantage of Plan 9 is that we 
have recognized that these are all essentially the same mechanism and have implemented them as such. 

3. Virtual Name Space 

When a user boots a terminal or connects to a cpu server, a new process group is created for her pro- 
cesses. This process group starts with an initial name space that provides at minimum a root ( / ), some 
binaries for the processor the process is running on (/bin/*), and some local devices ( /dev/ * ). The 
processes in the group can then either add to or rearrange their name space using two systems calls, mount 
and bind . The mount call is used to attach a new (not kernel resident) file system to a point in the name 
space. Its syntax is 

mount(int fd, char *old, int flags, ...) 
where fd is a file descriptor for a communication stream such as a pipe or a network connection and old is 



- 4 - 


the name of an existing file in the current name space where the file system will be attached. The attach- 
ment creates a new mount device channel whose communication channel is that referred to by fd. Subse- 
quent accesses to old and any files below it in the hierarchy become request messages written to the com- 
munication stream. 

The bind call is used to attach a kernel resident file system to the name space and also to rearrange 
pieces of the name space. Its syntax is 

bind (char *new, char *old, int flags) 
where new is a name in the current name spacet and old is the same as in mount. 

How the attachment works depends on the flags specified in the call. One possibility is that the old 
file is replaced by the new one. However, when both files are directories, Plan 9 allows another possibility. 
The result can be the union of the two directories. The effect is that of putting one directory behind the 
other. In the case of name conflicts for files contained in the directories, the one in front wins. Flags speci- 
fies whether the new directory replaces, goes in front of, or goes behind the old one. This concept is essen- 
tially the same as the search paths used in the Unix libraries and the various shells. In fact. Plan 9 has no 
search paths and uses these union directories in their place. When a command is executed, Plan 9 uses the 
directory /bin the same way Unix uses an execution path. 

The ability to specify the complete name space for a process that contains all resources the process 
can access forms the basis for a true virtual machine. Any aspect of a process’ world can be rearranged. 
Remote objects can be substituted for local ones. Processes can implement part or all of the name space of 
other processes. This capability is the basis for a number of important services, three of which we present 
here. 


3.1. The Cpu Command 

We consider the shared CPU servers as accelerators for our terminals, someplace where commands 
can run while maintaining the same environment. It is important that as little as possible change when run- 
ning on the CPU server. The virtual name space provides us with a means to make the CPU servers actu- 
ally feel this way to our users. A command, cpu , calls a CPU server across a network. A daemon process 
on the server answers the call, creates a new process group for the caller, sets up a name space, and starts a 
shell process in the new process group. The name space set up is an analogue of the name space of the call- 
ing process on the terminal. In particular, local resources on the terminal, such as the screen and the mouse, 
become visible to the server processes at the same place in the name space as on the terminal. The standard 
input, standard output, standard error, and current directory of the cpu command become those of the 
remote shell. The directories mounted on /bin are changed to be those that contain executables for the 
CPU server’s processor type (the terminal may be a 68020 while a CPU server could be a MIPS). In gen- 
eral, a user typing the cpu command just notices that things such as compilations speed up while graphics 
operations slow down. 

After the initial handshake to pass information describing the caller’s environment, the cpu command 
becomes a file server answering file system requests from the network connection. The server daemon 
mounts the network connection to the terminal in a standard place, /mnt/term, and then binds the 
resources it decides to keep into the same places in the new name space. For example, it binds 
/mnt / term/dev/mouse onto /dev/mouse, /mnt/ term/dev/bitbit onto /dev/bitbit, 
etc. Subsequent accesses to those files are converted by the mount driver in the CPU server into file system 
messages sent to the terminal. 


f Local kernel resources are referred to by a syntactic escape (hack) in the name space. Any name starting with a “#” 
refers to a local resource. The first character following the “#” specifies the type of resource and the remaining characters 
are a parameter specifying the instance of the resource. Thus, to bind the local console to a standard place in the name 
space, one would use bind( M #c", "/dev", FRONT). 
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3.2. The Window System 

The user interface is made up of three files: 

/dev/bi tbit - writes represent bitblt operations to the screen 
/dev/mouse - reads return mouse events, i.e., button clicks and movement 
/dev/ cons - reads return keyboard input, writes put characters to the screen. 

Between them, these devices represent all I/O to the user. The window system, 8.5 [Pik91], offers pro- 
cesses a multiplexed view to these devices. When a window is opened, the window system starts a new 
process group for a command (usually a shell) that will run in that window. In that process group’s name 
space, the window system mounts a pipe to itself in front of /dev . Subsequent references by the new pro- 
cess group to any of these devices are sent as file system messages to the window server. 8.5 interprets 
those requests as accesses of the window instead of the whole screen. Similarly, 8.5 multiplexes the mouse 
and the keyboard so that mouse and keyboard input is available to processes only when their window is 
selected. 

The result is that any program written to use the kernel resident user interface will also work inside a 
window. Because this is also true of the window system itself, new versions of the window system can be 
run and debugged in windows of the current window system. 

3.3. Network Gateways 

One, sometimes insurmountable, problem is accessing a network to which a system is not physically 
attached. For example, a system may be connected to our Datakit [Fra80] network but not to the DoD 
Internet. Many gateways exist that try to solve this problem by performing protocol to protocol translation. 
Unfortunately, few transport protocols have completely equivalent concepts. In order to perform the best 
translation, it is be necessary to know the semantics requested by the program. For example, TP4 has mes- 
sage delimiters but TCP does not. A protocol translator going from TCP to TP4 would not know which 
bytes correspond to a single write by the sender. 

In Plan 9, every network interface is a file system. A gateway is a file server that serves its own net- 
work interfaces to other machines. A process that wants to get at a remote network connects to the gateway 
and mounts the gateway’s interface to the remote network into its name space. Whenever the process 
accesses the interface, the mount driver will send the request to the gateway. Thus, the gateway sees 
exactly what the process does. 

4. File Caching 

In building our environment, we’ve been reluctant to add local disk file systems to any of our termi- 
nals or CPU servers. There are essentially two reasons for this choice. The first is administration. Anyone 
with a local disk must administer it. Any disk that has unique long term state requires both knowledge and 
time to administer. In fact, the Bell Labs computer center at Murray Hill is doing a lucrative business 
maintaining other peoples’ disked Sun workstations because the owners have neither the time nor the expe- 
rience necessary to do it themselves. 

The second reason is sharing. Although most workstations can export access to their local file sys- 
tems, when left up to individual users, this rarely happens. Terminals become personified and users 
become tied to a particular room to do their work. 

Plan 9 survives without local disk file systems thanks partially to hardware and partially to caching. 
The CPU servers do so because their links to the file servers transfer at a substantial percentage of memory 
speed. The file servers maintain large main memory caches for their disk file systems. These servers are 
configured with 128 megabytes or more of main memory to ensure that there is plenty of room for cache. 
Getting a file from a file server is generally faster than it would be to get it from a local disk. 

Office terminals are connected to the file servers by shared 1 or 10 megabit/sec links. Home termi- 
nals use 9600 or 19200 baud links. In both cases, the link is much slower than access to a local disk would 
be. To avoid the obvious performance hit, we use caching. To keep the caches coherent, we use file identi- 
fiers supplied by the file server. The identifiers are unique 64 bit quantities. 32 bits identify the file, the 
other 32 bits identify the version of the file. The version number is incremented each time the file is 
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modified. Each time a file is opened the file server returns the identifier with the reply. Therefore, it is 
possible to guarantee coherency at each opening of a file. 

Office terminals only cache pages of executable files. Whenever a program terminates, its unmodi- 
fied text and data pages are not immediately freed. Instead they are retained until the space is required by 
other programs. When a program is rerun its executable file is reopened and the current version number 
returned. If the version number has not changed and pages remain from the last run, they are reused. If the 
version number has changed, any remaining pages of the stale version are discarded. Since most data inten- 
sive work is done on the CPU servers, this simple cache saves most of the traffic between office terminals 
and the file servers. Other caching could be helpful but would require much more complexity. 

This cache might also have sufficed for home terminals if it were persistent, but it is not. Therefore, 
we have added disks to our home terminals to be used as write through caches of the file server files. As a 
write through cache, it contains no state that isn’t duplicated on the file servers. Therefore, it needs little 
maintenance compared to a local file system. If the code discovers a disk problem, it reformats the disk 
discarding the current contents. If the user should suspect that the cache is contaminated, she can request 
that it be reformatted at the next boot. The system slows down until subsequent use refills the cache but no 
information is lost. The user need not consciously update the disk because the cache uses file identifiers to 
maintain coherency with the file servers. Each time a file is opened, the cache discards any stale data it 
might have for that file. The user doesn’t have to copy what she needs to the disk because it is done as a 
consequence of her using the data. 

The disk based cache is implemented by a process that resides between the kernel and the file server 
connection. For every read request, the process satisfies as much as it can with data cached on the disk. It 
gets the rest from the file server. Any new data that passes through it is saved on the disk. When the cache 
fills up the least recently used file is discarded. The amount of data cached for any one file is limited to 
1.75 megabytes to prevent one file from displacing all others. 

Because the disk based cache only checks for coherency when a file is opened, it provides slightly 
different semantics than that seen on office terminals which do not cache data files. This looser coherency 
constraint forces programs that communicate via files to ensure an open between each transaction. Thus far 
we have not had to change any programs because of it. 

5. Conclusion 

We have presented a distributed system that is simple in structure and flexible in its use. Both the 
flexibility and simplicity are the result of two properties, a per process group name space and a single 
resource interface. Coupled with some minimal caching we provide a simple system that is as usable at 
home as at work. 
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README 


Brian W. Kernighan 

AT&T Bell Laboratories 
Murray Hill, New Jersey 07974 


This brief document is intended to help you get started using Plan 9. It is written by a casual Plan 9 
user who is not in any way part of the Plan 9 group, and is aimed at ordinary users with a Unix background. 

1. Getting Started 

I’m assuming that you or someone you trust has read, understood, and performed the instructions in 
the Plan 9 installation procedure. I’m also assuming that you have at least looked at the Plan 9 overview 
paper in Computing Science Technical Report 158, which explains what Plan 9 is and how it goes about it. 
There are also some helpful explanations and examples in the paper “The Use of Name Spaces in Plan 9,” 
which is also part of the distribution. I am further assuming that you have the Plan 9 manual near to hand, 
and are willing to read manual pages for commands as their names appear here. 

How you get started after you turn your terminal on depends on how your Plan 9 system is set up; the 
details are different for a standalone system or a terminal connected to a file server and a CPU server. The 
latter is mostly what I’ll talk about. 

When Plan 9 boots, it runs a very dumb terminal program, so dumb that it doesn’t even know how to 
scroll a screen. You won’t want to use that for much of anything. In much the same way that . profile 
is executed by the shell on Unix systems, the file lib/profile is executed by the shell on Plan 9 when 
you log in. The newuser command normally creates a few directories (bin, bin/rc, lib, and tmp), 
then sets up a profile 1 ib/prof i le that looks like this, though with some more frills: 

bind -a $home/bin/rc /bin • 

font = /lib/font/bit/pelm/euro . 9 . font 
switch ( $service) { 
case terminal 

prompt= ( ' term% ' ' ' ) 

exec 8 l A 

case cpu 

bind -b /mnt/term/mnt/8V$ /dev 
prompt= ( ' cpu% ' ' ' ) 

} 

Many of the interesting bits of Plan 9 are implicit in this file. 

2. Commands 

Most of the standard Unix commands exist in almost the same form on Plan 9; this includes standbys 
like cat, Is, cd, pwd, cp, mv, dif f, grep, awk, and so on. You’ll notice minor differences in behav- 
ior but for the most part you don’t have to think about this. 

3. The rc Shell 

# 

One big difference: Plan 9 uses a different shell, called rc. For running commands interactively, it’s 
almost the same as the Bourne shell, so filename metacharacters like * and ? behave the same, and simple 
redirections with > and » are the same (but not redirection of streams by number). Quoting is simpler 
than in the Bourne shell: double quotes and backslash have no special meaning, and single quotes quote 
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anything. To get a single quote into a quoted string, double the quote: 

echo ' ' ' ' 
prints a single quote. 

For programming, rc is almost unrelated, which is a nuisance. All shell scripts have to begin with 

# ! /bin/rc 

Environment variables are set by 
var = ' anything ' 

where the quotes can be omitted if anything contains no spaces. Environment variables are accessed as 
$var; certain variables are initialized when your process begins, including user (your name), home (your 
home directory), and service, which is terminal when you are running on your terminal. 

4. Directories and Search Paths 

One of the unifying ideas in Plan 9 is that all resources are accessed as file systems. Central to this is 
management of the name space so that you can select and arrange the resources you want to use. 

The bind and mount commands manipulate the name space. In particular, the command 

bind -a $home/bin/rc /bin 

in the profile binds the directory $home/bin/rc after the directory /bin, forming a union directory. 
(More precisely, it makes /bin an alias for the union). The shell searches only /bin for commands to 
run, but it searches all the directories that have been unioned together. By convention, your personal shell 
scripts are placed in $home/bin/rc. 

When you first log in, several directories are bound to /bin, including /rc/bin, which contains 
shell scripts, and /$cpu type /bin, which contains binaries for your current cpu type, cputype is the 
type of processor you are running on, typically one of 68020, spare, mips, or 386. When you run a 
program like Is, the version for your current cpu type will be found and executed. If you subsequently 
execute the cpu command to access a cpu server, in that process and those started by it, cputype will be 
the type of the cpu server, and the 1 s command you run there will be the right binary for that cpu. 

If you think about it, you can see that this mechanism of union directories replaces the search path of 
conventional Unix shells. As far as you are concerned, all executable programs are in /bin. Try 

lc /bin 

to see the names of all executable programs. 

5. Interesting File Systems 

Unix users are familiar with the idea that devices like disks and tapes are part of the file system. Plan 
9 carries that idea a lot further. If you look at the directory /dev, you will see some familiar names. Try 

cat /dev/time 

a couple of times, for example. Or, after you have snarfed some text using the button 2 menu item, try 

cat /dev/snarf 

Note that some files like cons and mouse occur more than once, /dev is a union directory, and these are 
multiple occurrences of the same file. The first /dev/mouse refers to the current window, and the next 
one to the enclosing window (which is probably the whole screen at this point). Try 

cat /dev/mouse 

then move the mouse around inside and outside of the current window. 

The shell environment is kept in a directory called /env; each shell environment variable is stored in 
a file. Try 
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cat /env/font 

for example. 

Running processes are found in /proc; each process is a directory, and each file in that directory 
accesses some aspect of the process. For example, the status file contains (all ASCII) status information 
about the process. Try 

awk '{print $ 1 }' /proc/*/status 

to get a list of the names of the running processes. 

You might also find it interesting to poke around in /net; all network connections are managed as 
file systems as well. In all of these cases, the service presents a file-system interface to its clients, although 
the implementation behind is not generally a traditional file system. 

6. The 8V2 Window System 

The window system for Plan 9 is called 8V2; the terminal case in the profile starts 8V2 with the line 

exec 8 X A 

8V2 provides much less of the “flexibility” and certainly far fewer features than xterm on X terminals, but 
I much prefer it. 

The most important difference is that 8V2 treats all text on the screen alike; with the mouse you can 
edit anything you can see, so you can fix up and resubmit commands, fiddle the output of a program or its 
input and resubmit it, and so on. This ability to edit the past is liberating to such a degree that once you use 
it, you’ll never want to go back to something like xterm. (There is an implementation of an X server so 
you can run it if you want, but I never have.) 

8V2 does not provide any of the terminal-handling mechanisms like termcap or curses. That means 
that there is no support for (nor indeed implementation of) old favorites like vi, emacs, and ksh. In my 
experience, the ability to cut, paste, and edit what’s on all the windows on the screen obviates the need for 
many of the mechanisms in these programs, so it’s not as big a loss as you might think. 

8V2 can be called recursively: you can make a new window, run 8V2 in it, and everything you do there 
is insulated from the surroundings. 8V2 does not provide any analog of the virtual window management of, 
for example, VTWM, nor does it provide zillions of (or even a few) icons, but you can move a window 
almost off the screen, and you can hide it and then recall it from a popup menu. 

You can also give 8V2 a file of commands to run when it starts, which most people put into their pro- 
file: 

exec 8 X A -i lib /windows 

Normally this is used to set up windows that you always use: 

#! /bin/rc 

w i ndow ' xO yO x 1 yl ' command line 

where xO,yO and xl,yl are the coordinates of the window in question (and x increases down the screen). 
The window command opens a window at the specified place, then runs the command in it. The command 
wloc will tell you the names and locations of all windows in the right format to be inserted directly in a 
file. Set up the windows and programs the way you want them, then run wloc and snarf its output. 

7. Fonts 

One aspect of 8V2 that you can change is the font it uses for displaying text. There is a default font, 
but normally the variable font is set explicitly in the profile: 

font = /lib/font/bit/pelm/euro. 9 . font 
8 A -f $font 

The font euro . 9 . font is a collection of almost any character you might find in European languages, 
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including Cyrillic, Greek, and a bunch of special characters. There are other fonts that include oriental lan- 
guages as well, and a variety of sizes. 

Plan 9 uses the Unicode character set throughout, which means that the system and the various pro- 
grams all deal pretty comfortably with a very large character set. (Think 16 bits, or 65K characters.) So if 
you want to edit files in languages that use more than ASCII characters, or run grep or awk over them, it 
just works. (You may have trouble printing such characters on standard printers, but they will appear fine 
on the screen.) 

8. Editing 

The standard Plan 9 editor is called sam; it’s a particularly good multi-file editor, it provides regular 
expression syntax the same as in the venerable ed (which also exists), and you can snarf text from one of 
its windows and paste it into other 8 Vi windows or vice versa. The mouse idioms for sam and 8 V 2 are the 
same. It will also edit files on other systems if there is a network connection. 

By the way, regular expressions have been cleaned up - all programs support the same regular 
expressions, which are pretty close to those found in egrep on Unix systems. 

9. The CPU Server 

In the Plan 9 world view one is meant to run interactive programs like editors on the terminal and 
compute-intensive programs like compilers on a cpu server, which runs faster and has a higher bandwidth 
to the file server. The cpu command connects you to a cpu server so your computation runs faster (in the- 
ory), but everything else stays the same. The mechanism is quite different from either remote login (which 
does not preserve the name space you are currently working in) or network file system access (which does 
not change the processor). The line 

bind -b /mnt/term/mnt/8 1 /^ /dev 

in your profile arranges that all the devices (including mouse, keyboard and screen) associated with your 
terminal are inherited by the cpu server so they continue to work in a cpu window. 

10. Connecting to Unix Systems 

It is highly likely that your Plan 9 system will be connected by some network to a Unix system. The 
command con connects to another system (typically Unix); the command rx is rather like the rsh com- 
mand on Unix systems, for executing a single command on another machine. 

If the Unix system cooperates, it is also possible to mount a Unix file system in the Plan 9 name 
space so that files on the Unix side are accessible from Plan 9. The command 

9fs machine 

establishes the connection and mounts the files; thereafter the root of the target file system is in the Plan 9 
directory at /n /machine. 

There is no connection from Unix to Plan 9; security is taken seriously (no superuser, for example) 
and it’s hard to provide a satisfactory mechanism. 

11. Backup and Recovery 

Normally the state of the Plan 9 file system is recorded every day or so; on our system, it’s stored on 
an optical disk. If your Plan 9 system is suitably equipped, you should be able to run another service that 
makes the past state of the file system accessible (read only). The command 

9fs dump 

mounts this file system on /n/dump. At that point, I can cd into the past: 

cd /n/dump/1991/0401/usr/bwk 
Is -1 

puts me in my directory as it was on April 1, 1991. This really is a file system, so all the normal commands 
work fine; I can dif f a file from then with one on some other date, or copy an old version to the present. 
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Plan 9 has no backup or recovery programs; this mechanism subsumes them all. 

12. Programming in Plan 9 

Most programming in Plan 9 is done in ANSI C, with the usual supporting tools like YACC avail- 
able. One difference of note: make has been largely supplanted by mk, which is cleaner but different. As 
with the shell, it takes time to internalize the differences. 

There are separate C compilers for each supported cpu type (badly named with a single letter 
mnemonic), but each compiler can produce code for any object type. The mkf ile normally encapsulates 
this. 

Although ANSI C is supported, the Plan 9 libraries are not ANSI and the standard ANSI header files 
normally are not found. Compiling C programs is different enough that you should read the paper called 
“How to Use the Plan 9 C Compiler” before starting. 

If you are importing or exporting a C program, you will want to use the ANSI/POSIX environment 
(“ape”), which really does provide for portability, including a complete set of POSIX-compatible libraries 
and some POSIX tools. The compiler driver is called pc c. The commands 

bind -a /bin/ape /bin 
bind -a /rc/bin/ape /bin 

will bind the right files. 

13. Envoi 

Plan 9 is not Unix. If you think of it as Unix, you’ll often be frustrated because something doesn’t 
exist or works differently. If you think of it as Plan 9, however, you’ll find that most of it works very 
smoothly, and that there are some really neat ideas that make things much cleaner than you have seen 
before. 
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